1. Technical Field
The present invention relates in general to data processing and, in particular, to a method and system for enhancing the performance of an object-oriented processor. Still more particularly, the present invention relates to a method and system for improving the performance of an object-oriented processor by caching intermediate data such as pointer values.
2. Description of the Related Art
Historically, one of the chief obstacles to harnessing the full computing power of computer networks including diverse hardware platforms has been interoperability. Thus, operators of nonhomogeneous networks have had to expend significant resources to be able to port software and permit communication between the diverse hardware platforms within the networks. The need for simple and inexpensive solutions to the problems of intercommunication and software portability has been made even more pressing by the relatively recent popularization and rapid expansion of the Internet and World Wide Web.
In order to address these longstanding problems, programming languages like Java.TM., which was developed by Sun Microsystems, Inc. of Palo Alto, Calif., have recently gained prominence. Java.TM. is a compact platform-neutral object-oriented programming language that, when compiled, represents instructions as platform-independent byte codes. These byte codes can be directly executed by a Java-specific processor or can be executed utilizing a software interpreter or a Just-In-Time (JIT) compiler that converts the Java.TM. byte codes into instructions within the native instruction set of a particular hardware platform.
Referring now to FIG. 1, the data structures of Java.TM.-compliant objects are illustrated. As depicted, Java.TM.-compliant objects can be either of two types: objects with handles or handleless objects. Objects with handles have a objectRef that points to an objectHandle 10, which contains pointers (denoted by asterisks) to each of objectData 12 and methodTable 16. ObjectData 12 includes a length declaration, various flags, and n+1 data words constituting the object's data. Methodtable 16, on the other hand, includes a pointer to an object class descriptor (classBlock 18) and pointers to m+1 methodBlocks 20, which each contain byte codes forming a method that can be executed against all objects within the same class. Thus, all objects within the same class share a common methodTable 16. Information describing the class associated with methodTable 16, including pointers to the className, methodBlock, methodTable, and methodTableSize, are collected within classBlock 18.
As illustrated in FIG. 1, handleless objects are much the same as objects with handles except that handleless objects lack an objectHandle. For handleless objects, the information contained in objectHandle 10 and objectData 12 have been merged into object 14, which includes a length declaration, various flags, and n+1 data words constituting the object's data. In addition, object 14 includes a pointer to an associated methodTable 16 shared by all objects within the same class.
Regardless of whether objects are implemented with handles or as handleless objects, the execution of a Java.TM. application entails the invocation of specified methods against particular instances of objects. Java.TM. includes a number of different byte codes for invoking methods (e.g., invokevirtual.sub.-- quick), each of which is hereinafter referred to as methodInvoke. When a methodInvoke byte code is processed, the objectRef parameter of the methodInvoke is utilized to access either an objectHandle or object, which is in turn accessed to locate the appropriate methodTable for the class including the specified object instance. Finally, the methodTable is accessed to identify the entry point of the method that is to be executed against the specified object instance.
The present invention includes a recognition that methodInvoke is one of the most frequently encountered byte codes in typical Java.TM. applications. The present invention also includes a recognition that Java.TM. applications often execute the same method against multiple object instances belonging to the same class. Although all object instances in a given class share a common methodTable, conventional processors redundantly perform the three-level table lookup described above to determine the entry point of each method, despite the fact that the intermediate determination of the location of the methodTable yields the same results for each object instance in the same class.
As should now be apparent, it would be highly advantageous and desirable to provide a mechanism for rapidly mapping method invocations to particular methodBlocks while minimizing the redundant calculation of methodTable entry points.